Conversation
There was a problem hiding this comment.
Pull request overview
This PR integrates PostHog analytics into the application to track user behavior and application usage. The integration includes both client-side JavaScript tracking and server-side Ruby event capture.
Changes:
- Added PostHog Ruby gem and client-side JavaScript integration for analytics tracking
- Implemented PosthogService with methods for capturing events and identifying users
- Added analytics tracking for key user actions: signups, sign-ins, settings updates, API key rotation, onboarding flow, and heartbeat submissions
Reviewed changes
Copilot reviewed 9 out of 10 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| Gemfile | Added posthog-ruby gem dependency |
| Gemfile.lock | Locked posthog-ruby version 3.4.0 with concurrent-ruby dependency |
| .env.example | Added PostHog configuration environment variables (API key and host) |
| config/initializers/posthog.rb | Initializes PostHog client with configuration and error handling |
| app/services/posthog_service.rb | Service class providing capture, identify, and capture_once_per_day methods for analytics tracking |
| app/views/layouts/application.html.erb | Embedded PostHog JavaScript snippet for client-side tracking with user identification |
| app/models/user.rb | Added analytics tracking for new user signups |
| app/controllers/users_controller.rb | Added tracking for settings updates, API key rotation, and onboarding steps |
| app/controllers/sessions_controller.rb | Added tracking for sign-ins (HCA, Slack, email), GitHub linking, and sign-outs |
| app/controllers/api/hackatime/v1/hackatime_controller.rb | Added daily tracking for heartbeat submissions |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| api_key = current_user&.api_keys&.last | ||
| api_key ||= current_user.api_keys.create!(name: "Wakatime API Key") | ||
| @current_user_api_key = api_key&.token | ||
| PosthogService.capture(current_user, "setup_started", { step: 1 }) | ||
| end | ||
|
|
||
| def wakatime_setup_step_2 | ||
| PosthogService.capture(current_user, "setup_step_viewed", { step: 2 }) | ||
| setup_os = detect_setup_os(request.user_agent) | ||
|
|
||
| render inertia: "WakatimeSetup/Index", props: { |
There was a problem hiding this comment.
Bug: The methods wakatime_setup_step_2 and wakatime_setup_step_4 are defined twice. The second definitions overwrite the first, causing PostHog analytics tracking calls to be skipped.
Severity: HIGH
Suggested Fix
Remove the duplicate method definitions for wakatime_setup_step_2 and wakatime_setup_step_4 in app/controllers/users_controller.rb. Consolidate the intended logic into a single definition for each method, ensuring the PostHog tracking calls are retained.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: app/controllers/users_controller.rb#L56-L67
Potential issue: In the `UsersController`, the methods `wakatime_setup_step_2` and
`wakatime_setup_step_4` are each defined twice. In Ruby, the second definition of a
method overwrites the first. As a result, the initial definitions, which contain logic
for capturing PostHog analytics events (`setup_step_viewed` and `setup_completed`), will
never be executed. The application will silently run the second, simpler definitions,
leading to a loss of analytics data for steps 2 and 4 of the Wakatime setup flow and
potentially incorrect rendering behavior.
Did we get this right? 👍 / 👎 to inform future reviews.
| def wakatime_setup_step_3 | ||
| api_key = current_user&.api_keys&.last | ||
| api_key ||= current_user.api_keys.create!(name: "Wakatime API Key") | ||
|
|
||
| @current_user_api_key = api_key&.token | ||
| PosthogService.capture(current_user, "setup_step_viewed", { step: 3 }) | ||
| end |
There was a problem hiding this comment.
Bug: The wakatime_setup and wakatime_setup_step_3 controller actions are missing explicit render calls, which will cause a ActionView::MissingTemplate error at runtime.
Severity: CRITICAL
Suggested Fix
Add an explicit render call to both the wakatime_setup and wakatime_setup_step_3 methods. Based on the other actions, this should likely be render inertia: "WakatimeSetup/Index" and render inertia: "WakatimeSetup/Step3" respectively.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: app/controllers/users_controller.rb#L79-L85
Potential issue: The controller actions `wakatime_setup` and `wakatime_setup_step_3` in
`UsersController` lack an explicit `render` or `redirect_to` call. Since the controller
uses the Inertia.js framework, it expects an explicit `render inertia: "ComponentName"`
call to render the corresponding frontend component. Without it, Rails' default
rendering mechanism will fail to find a conventional template (e.g.,
`wakatime_setup.html.erb`), resulting in an `ActionView::MissingTemplate` error and
crashing the user's request when they access these setup steps.
Did we get this right? 👍 / 👎 to inform future reviews.
(For analytics!)